Although the present invention has a quite broad range of applications, it will be set in contrast to a specific prior art, i.e., a maintenance or management tool for a product catalog which is offered via the Internet. An example is a merchant's commerce system like the “WebSphere CommerceSuite”, provided by IBM. Nevertheless, the invention is applicable to any other structured agglomeration of data which can be represented in a directed graph and can be described with an entity relationship model. Further examples are business models which are also mapped into such representation or other data maintained within a relational database structure.
Thus, the sample data in the above sense is the data related to the products, as e.g., product names, generic names for certain product groups, or generic names for meta groups comprising several of said product groups, as well as product attributes and the usual overhead data, as e.g., a catalog contents list and further supplementary information, like text, image or multimedia information, relating to individual products, product groups, or articles. Articles are herein understood as a buyable product, i.e. a product with all attributes necessary to place an order specified.
The example of a catalog is chosen as the products presented in the catalog can be very numerous and sorted in an ambiguous manner within the graph. The graph may thus include meshes.
First, Catalog Maintenance will be discussed next below:
When a catalog is offered via the Internet, i.e. a web catalog, instead of a book which is usually issued once or twice per year, the problem of maintaining the product asset up-to-date is even more visible because any maintenance work should be done quite quickly and free of errors, otherwise the catalog cannot be visited online by the clients, or in case of errors, the clients could be confused.
A (web) catalog contains information about the articles to sell, like a language dependent name, some description, a number for the Enterprise Resource Planning (ERP) system of the merchant, and it often contains the price for the article. There is also the option to store different attributes to an article, like the color or size information, for example. The types of these attributes might be different for different groups of articles. For some articles like clothes the size and color are relevant while for others, maybe the weight is the relevant attribute.
The merchant cannot just present the customer a flat list of articles to buy, because usually the list would be too long and the customer would not be able to find the desired goods. Therefore the articles are organized into groups. All articles in a group will have a common generic type (e.g., poem books has the generic type ‘books’, or handcraft tools that of ‘tools’, or women's trousers that of ‘trousers’ or clothes, if structured like that . . . ). One article or product can be in more than one group. The groups itself might be grouped again until the number of items is small enough to be presented to the customer. There is also the option to store different attributes to a group.
Now there are two general problems for a merchant offering such catalog:    1. The articles thereof have to be maintained. This task includes maintenance of the type of article and of the attributes for each article. Also the grouping of articles and the groups have to be maintained. This includes the attributes for the groups, as well as the relationship among groups and between groups and articles.    2. The relation between articles (or groups) and possibly supplementary information in an associated content- or document management system needs to be defined and maintained.
It can easily be seen, that a program application, i.e., a management or maintenance tool for maintaining the catalog information is needed. Such tool must provide the functionality, for example to add, edit, or remove a catalog node, product or article.
In prior art, such tool exists. It is usually strongly customized because it depends on the specific data model of the respective particular catalog actually in question.
In a very basic approach there would be for example one table for trousers and another for shirts and so on, i.e. the database structure to store the catalog reflects the group relations. This prohibits the use of standard catalog maintenance software, as the specific catalog structure must be programmed into the catalog maintenance tool. The reason is that not all merchants do offer the same products and articles.
In a more common approach all articles are stored in one set of tables (e.g. one for the article, another for the attributes etc) and the groups in a different set of tables. Here, however, it is difficult for the maintainer to find the right parents or children when creating relationships: The maintainer has to select the nodes from a large list. This is a large source for generating maintenance errors.
Currently, the intelligence to support a catalog maintainer in this task is program logic built-in directly into the maintenance tool in use. This means the intelligence (rules) to handle each type of catalog node is directly programmed into the maintenance tool. For example there are custom queries programmed into the tool to find the possible children for a selected node type. Also the set of attributes for different types of articles is programmed into the maintenance tool such that the correct GUI can be presented to the catalog maintaining person. This limits the use of standard ‘off the shelf’ catalog maintaining (management) software.
On the other hand, there exist also generic catalog maintenance tools. Those tools, however, rely on the intelligence of the catalog maintainer, as the tool itself has no knowledge about the type of the content. This user has to make sure that all necessary fields are filled-in and no wrong relationships are defined. This restricts the possible number of users, because a maintaining person must have excellent knowledge on the products offered within the catalog. Further, due to this fact, this kind of generic tool is only usefully applicable for small catalogs.
Thus, catalog maintenance is difficult, complicated and expansive for a merchant.
Next, the relationship between catalog maintenance and Content- and Document Management will be discussed with respect to prior art disadvantages:
It is not always feasible to store all information about an article in the catalog itself. Often, the merchant has some content- or document management system, in which he manages documents (e.g. office documents or PDF files) that hold relevant information about the article for the customer. The merchant often chooses to manage those documents in such a management system because he wants to use the workflow and release management of those tools.
The relationship between an article to its supplementary information is realized in prior art according to basically two different approaches. The first is by exchanging internal keys of one system (catalog or document management system) into the other. That means storing the internal identifier of a document in the document management system as an attribute of the article in the catalog and vice versa. This prior art approach has the disadvantage that the internal identifiers are not permanently the same, i.e., stable. For example, deleting a document or an article and recreating will most likely yield a different internal identifier for the newly created article, because they are generally automatically created. Thus, the other system must be updated also. This is a significant disadvantage.
The second approach in use involves meta-information about the structure of the catalog and the way the documents are maintained in the document management system. That is for example, when the documents in the document management system are organized in the same (file-)structure as the articles are stored in the catalog, or when the application ‘knows’ where to look for information about this article in the document management system, due to a ‘hard-wired’ link. This, again, limits the use of standard software or restricts the structure in one of the two systems (catalog or management system).
A further problem of today's technology, in particular when applied via the Internet, is that the internal identifier is used in the URL that is given to the customer. The customer might run into problems that the URL is no longer valid, if he selects to put a bookmark on the page pointed to by the URL, and the database had to be reloaded. This also happens, if someone wants to put a link to the article on his own web page.